![SpectaclesでLooker(LookML)のテストをやってみた](https://devio2023-media.developers.io/wp-content/uploads/2021/06/spectacles-logo_1200x630.png)
SpectaclesでLooker(LookML)のテストをやってみた
大阪オフィスの玉井です。
Spectaclesを実際に使ってみました。
Spectaclesとは
下記の記事で説明されています。
もう少しシンプルかつざっくりいうと、指定したタイミングでLookMLやコンテンツのテストを行ってくれるツールです。Lookerのための自動テストツールって感じでしょうか。
現在、Spectaclesを利用するためには、公式サイトからデモ依頼を行う必要があります(デモをやってもらった後、トライアル環境がもらえる)。当然、英語でやり取りをするので、私は翻訳サービスを駆使してなんとかがんばりました。
やってみた
Looker側の準備
Spectaclesは、LookerのAPIを利用して、各種テスト(バリデーション)を実施するので、先にSpectacles用のAPIを用意する必要があります。公式の推奨として、Spectacles用のユーザーを個別に作ったほうが良いとあるので、今回はユーザーも作ります。
Permission Setの作成
Spectacles用ユーザーのためのPermission Setを作ります。ドキュメント曰く、下記の権限が必要とのことです。
Roleの作成
Spectacles用ユーザーのためのロールを作ります。Model Setは、実際にテストしたいモデルやExploreがあるModelを見られるようなModel Setを使います。Spectacles側でテストをかけるModelやExploreは指定できるので、今回はとりあえずAllでいきます。
ユーザーの作成及びAPIキーの発行
Spectacles用ユーザーを作成し、APIキーの発行をします。
Spectaclesの設定
初期設定
いよいよ、Spectaclesを使っていきます。今回はGUI版を使います。
トライアル環境にアクセスすると、こんな感じです。
最初に、Lookerインスタンスの情報を求められます。適切な情報を入れます。APIのキーとシークレットもここで入力します。
設定完了まで待ちます。
設定が終わってトップ画面が表示されます。こんな感じです。後は、対象のLookML Projectを指定するだけです。
GitHubの設定
Spectaclesは、テストの実行タイミングとして、「(LookMLの)Gitリポジトリへのプルリク時」を指定できます。これを使うことで、まさに継続的インテグレーションって感じの運用ができるのですが、プルリクのタイミングをSpectaclesでキャッチするために、設定画面でGitHubの連携認証を行う必要があります。注意点としては、LookML Projectで使っているGitHubと同じアカウントで認証しないと、そもそも意味がないというところですね。
連携認証自体はクリックするだけの簡単な作業です。
Spectaclesで色々テストをする
諸々の設定が完了したら、実際に色々使っていきたいと思います。
Spectaclesでは、1つのタスク(どんなテストをどういうタイミングで回すか)をSuite
と呼称します。ですので、まずはSuiteを設定しましょう。
Suiteについて
メニュー画面の上から、Suiteの作成画面に遷移できます。まずは、名前と実行タイミングを指定します。今回は簡単な検証目的なので、時間を選びました。ちなみに、別途手動実行も可能です。
1つのSuiteの中に、3種類のValidatorを組み合わせることができます。1つずつ見ていきましょう。
SQL Validator
これは、LookML上のsql
パラメータ内に記述されているSQLが間違ってないかチェックできます。Looker側では、中のSQLまではチェックされないので、非常に有用な機能といえます。ちなみに、実際にクエリを実行してチェックするので、LookerとDWHが動作するという点はおさえておきましょう。
Explores to query
で、*/*
と書くと、Project内の全Model(全Explore)をバリデーション対象にします。model_a/explore_a, model_a/explore_b
みたいに、個別に指定することもできます。Explores to exclude
は、その名の通り、対象外にしたいModelやExploreを指定できます。Fail fast
は、一発目のエラーが出た時点でSuiteを止めるかどうか、という設定ですね。最後の数値はクエリの同時実行数です。
実際にSuiteを作って手動実行します。
実行する環境を選びます。Productionはともかく、Developmentモードの各ブランチ単位で実行できるのは便利ですね。
定期実行でしばらく放置すると、こんな感じで履歴が見れます。
1つの実行結果の詳細はこんな感じ。
ちなみに、エラーの場合(sqlパラメータの中のクエリが実行できなかった場合)、下記のように表示されます。
Content Validator
その名の通り、Lookerのコンテンツバリデーターとやることは一緒です。ただし、本家はインスタンス全体でしか実行できないのに対し、こちらはProject単位やModel、Explore単位で実行することができます。
設定によって、個別フォルダ内のコンテンツは対象外にすることができます。Only incremental errors
というのは、Production環境のコンテンツエラーは無視します。ドキュメント曰く、ブランチの変更で発生したコンテンツエラーを把握するのに役立つ、とのことです。
問題がない場合は下記のように表示されます。
エラーがあった場合(コンテンツが壊れていた場合)、下記のように表示されます。これは、コンテンツに使わているフィールドの名前が変わって参照できなかったパターンです。
ちなみに、現在、Exploreの名前が変わったエラーについては認識できない、という仕様があります。Exploreごと消えてるので、それがエラーなのか、そもそも無いのか、というのが判断できなからっぽいです。これは下記のIssueで改善中とのことです。
Assert Validator
これは、LookMLに記述されているデータテストをチェックするものです。LookMLのtest
については、下記をどうぞ。
設定は一番シンプルです。
成功例
エラー例(test
の内容が通らなかった)
Slack配信
Suiteでエラーが発生した時に、Slackに通知させることができます。設定画面でSlackの認証を行うだけです。
考慮事項
Gitリポジトリについて
Looker側で使用しているのがGitHub以外の場合、Spectaclesのプルリクトリガーは使えない気がしました(未検証)。
こんなのがあれば
LookML側で定義されているtest
やsql
などが、Spectacles側でザザッと見れたら便利かな、と思いました。Spectacles側でバリデーションする内容を把握したい、という感じですね。
おわりに
今回は手動実行で各バリデーションを検証したに過ぎませんが、プルリク時にSuiteが発動するようにすれば、LookMLを開発している過程で必ずチェックが通るようになるので、本番環境に間違ったコードを上げなくて済む→LookMLの品質を保てるようにできます。
私がもう一つ注目しているのは、dbtとの連携です。dbt側のプルリクに合わせてSpectaclesが動作し、dbt側の変更によって、LookML側の(テーブル等への)参照が一致しなくなった時に、エラーを返してくれたりするそうです。こちらも、どこかでブログにしたいと思います。